home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1059 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.2 KB
  1. Date: Wed, 27 Jul 1994 00:43:08 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: GEM, etc.
  4. To: gem-list@world.std.com
  5. In-Reply-To: <m0qSvfr-0000Q5C@sdf.lonestar.org>
  6. Message-Id: <Pine.3.87.9407270008.D12152-0100000@grad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10. Gem-List people:
  11.  
  12. Well, after much thought, I have decided to abandon the German 
  13. user-interface attitude of so overloading the interface with [sometimes 
  14. marginally useful] features that the program becomes unusable.
  15.  
  16. Instead, I am going to stick to a sensible, useful interfacing attitude 
  17. that aloows both the developer and the user to get work done in a 
  18. reasonable amount of time.
  19.  
  20. I see absolutely no point in going through all the trouble of adding 
  21. countless features and options, 90% of which will not be used in any 
  22. particular situation.  I want a window-library that makes my life easy 
  23. with documentation that takes me less than a week to read and understand, 
  24. well-commented, readable code, and simple bindings.
  25.  
  26. I see no point in absolutely abandoning the GEM style.  It makes sense to 
  27. make some modifications, yet some of the things you people are talking 
  28. about like sending key-presses to a background window are not only hard 
  29. to implement and counter-intuitive, but possibly DANGEROUS.  I will not 
  30. send keypresses to a background window, and unless it's absolutely 
  31. necessary, I don't see any point in sending mouse-clicks to a background 
  32. window either.  It's just not GEM and it will only confuse and frustrate 
  33. people.
  34.  
  35. I see no point in screwing with GEM's top-window-had-focus method.  A 
  36. tool bar in a background window doesn't, as far as I'm concerned, have 
  37. focus when you click on it, so it's just fine with me.  I do not like 
  38. giving focus to anything other than the top window.  The X-windows method 
  39. is OK, but we're not using Xwindows... we're using GEM.  Don't forget that.
  40.  
  41. I want users to like my applications.  I want users to be able to use my 
  42. applications.  Therefore, I will give the user only what he needs to be 
  43. able to accomplish his task effectively.
  44.  
  45. I am writing a window library.  At the present it is about 20k.  Already, 
  46. it cuts userinterface development for me into a small fraction of the 
  47. time it took before.  It sets things up for me, does amodal dialogs, and 
  48. handles and directs window events automatically for me.  It also makes 
  49. any application that runs under it a little more object oriented, 
  50. treating each window as a seperate object and giving the application 
  51. simple means to handle data independantly for each window.
  52.  
  53. With that, I have to ask what is in some of these other libraries that 
  54. take up over 200k?  Loads and loads of more features.... most of which 
  55. someone looking to get work done would never use.
  56.  
  57. My library will continue to grow, but I doubt it will grow to more than 
  58. 50k, and I will always strive to make it simpler and simpler to use while 
  59. it gets more and more powerful.
  60.  
  61. Evan:
  62.  
  63. ]========================================================================
  64. ]handling clicks on the desktop.  The point was to simulate WF_BEVENT in
  65. ]normal TOS.  With normal TOS, if I click on a window, the window gets a
  66. ]WF_TOPPED message.  Since I want to avoid that, I have to handle mouse
  67. ]========================================================================
  68. ]
  69. ]No, you just convert the WF_TOPPED message to button clicks.  You
  70. ]can't do drags and such under normal TOS from a background window, unless
  71. ]you use the right button.
  72.  
  73. Am I not getting my point across?  I want to do drags in background 
  74. windows in normal TOS.  I KNOW how to convert WF_TOPPED messages into 
  75. button clicks.  I'm already doing it!  I want to do drags too.
  76.  
  77.  
  78. BTW, I'm using a Falcon 030.
  79.  
  80.  
  81.  
  82. ]As to where to put it, no one has even agreed to the above.  They are
  83. ]still arguing about ^A and trying to vote on it.  Damn stupid to vote
  84. ]on ^A when you can configure it instead.
  85.  
  86. It's not stupid.  For one thing, I do not like the config file.  
  87. Secondly, if anyone uses Ctrl-A for select all, they're going to be in a 
  88. mess without a lot of hacking.  It's just TOO EASY to hit Ctrl-A, and I 
  89. don't want something as dangerous as Select-All assigned to it.  It's 
  90. perfectly logical.
  91.  
  92. Something dangerously easy to hit like Ctrl-A should have something 
  93. totally harmess assigned to it like Redraw-window.
  94.  
  95.  
  96.  
  97.